home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group93a.txt / 000043_icon-group-sender _Sun Jan 24 12:19:12 1993.msg < prev    next >
Internet Message Format  |  1993-04-21  |  2KB
  1. Received: by cheltenham.cs.arizona.edu; Sun, 24 Jan 1993 10:48:39 MST
  2. Date: Sun, 24 Jan 93 12:19:12 EST
  3. From: Paul_Abrahams@MTS.cc.Wayne.edu
  4. To: icon-group@cs.arizona.edu
  5. Message-Id: <556329@MTS.cc.Wayne.edu>
  6. Subject: Rremoving entab/detab from Icon
  7. Status: R
  8. Errors-To: icon-group-errors@cs.arizona.edu
  9.  
  10. I may have used entab/detab occasionally, but I don't remember using
  11. them.  Moving them to the library would make sense, however, only if
  12. semantic equivalence could be guaranteed, i.e., one could always repair a
  13. program using entab/detab by adding appropriate library loads.  Lacking
  14. such equivalence, it would be a mistake to remove them from the language.
  15. Incompatible change is dangerous--you never know who will get stung, or
  16. with what effect.
  17.  
  18. That principle, of course, can be carried to extremes.  While deleting
  19. merely useless facilities isn't worth the hazard, deleting facilities
  20. that interfere with sensible programming often is justified.  Some of the
  21. changes from K&R C to ANSI C probably fall into that category.
  22.  
  23. The best example I can think of of a terrible language facility that is
  24. almost impossible to remove is the COMMON/EQUIVALENCE stuff in Fortran.
  25. I haven't followed developments in the Fortran world for a long time, but
  26. I know that people have been most hesitant to tinker with COMMON/
  27. EQUIVALENCE because of how the changes might impact programs in use in
  28. critical applications such as aeronautical engineering and nuclear power
  29. plant control.
  30.